Перейти к основному содержимому

6.07. Требования

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВВ РАЗРАБОТКЕ
Аналитику Архитектору Руководителю Техническому писателю

Требования

Что такое требование?​

В контексте разработки программного обеспечения и управления ИТ-проектами требование — это формализованное, проверяемое и однозначное описание потребности, ожидания или ограничения, предъявляемого к продукту, системе, процессу или его компонентам. Требование служит основой для проектирования, реализации, тестирования и сопровождения решения. Оно отражает то, что должно быть сделано, а не как это должно быть сделано.

С научной точки зрения, требование — это утверждение, фиксирующее желаемое состояние системы или её поведение в определённых условиях. Ключевое свойство требования — его возможность быть интерпретированным однозначно всеми участниками проекта: аналитиками, разработчиками, тестировщиками, заказчиками и экспертами предметной области.

Не следует путать требование с пожеланием, идеей или задачей. Пожелание («Хотелось бы, чтобы система работала быстрее») — это неформальное выражение потребности и не является требованием до тех пор, пока оно не будет уточнено, измерено и формализовано («Система должна обрабатывать 10 000 запросов в секунду при задержке не более 200 мс»).

Управление требованиями как дисциплина​

Управление требованиями (Requirements Management, RM) — это систематическая дисциплина, охватывающая полный жизненный цикл требований: от их выявления до реализации и последующей поддержки. Она включает в себя процессы планирования, сбора, анализа, спецификации, верификации, валидации, отслеживания и контроля изменений.

Главная цель управления требованиями — обеспечить, чтобы система, в итоге реализованная, соответствовала реальным потребностям заинтересованных сторон, а также чтобы все требования были прослеживаемы, согласованы, реализуемы, тестируемы и приоритизированы.

В практической работе управление требованиями предотвращает такие типичные проблемы, как:

  • упущенные или недопонятые функции,
  • избыточные или противоречивые требования,
  • «размытые» цели проекта,
  • постоянные изменения без контроля,
  • несоответствие конечного продукта ожиданиям заказчика.

Роль аналитика в этом процессе — не только фиксировать, но и структурировать, анализировать, согласовывать и поддерживать актуальность требований на протяжении всего проекта.

Классификация требований по BABOK​

Согласно Business Analysis Body of Knowledge (BABOK v3) — международному стандарту в области бизнес-анализа, — требования делятся на четыре категории:

  1. Бизнес-требования (Business Requirements)
    Отражают стратегические цели и высокий уровень результатов, которых организация стремится достичь. Формулируются на уровне компании или подразделения. Пример: «Сократить время обработки заказов на 30 % за счёт автоматизации складских операций».

  2. Требования заинтересованных сторон (Stakeholder Requirements)
    Описывают потребности отдельных групп или лиц, чьи интересы затрагивает система. Эти требования служат мостом между бизнес-целями и технической реализацией. Пример: «Оператор склада должен видеть статус каждого заказа в реальном времени».

  3. Требования к решению (Solution Requirements)
    Детализируют характеристики самого продукта или системы. Подразделяются на:

    • функциональные (что система делает),
    • нефункциональные (как хорошо она это делает: производительность, безопасность, удобство и т.д.).

  4. Переходные требования (Transition Requirements)
    Временные условия, необходимые для перехода от текущего состояния к будущему. Актуальны только в процессе внедрения. Пример: «Система должна поддерживать параллельную работу со старой и новой платформой в течение трёх месяцев».

Эта классификация важна, поскольку позволяет аналитику выстраивать логическую цепочку: от стратегии бизнеса → к интересам пользователей → к архитектуре и функциональности → к условиям внедрения.

Типы требований в IT-практике​

В инженерной среде, особенно в разработке ПО, чаще используют более прикладную классификацию, ориентированную на техническую реализацию:

  • Функциональные требования
    Описывают поведение системы: какие действия она должна выполнять в ответ на определённые входные данные или события. Пример: «При нажатии кнопки «Отправить» система должна валидировать форму и отправить данные на сервер».

  • Нефункциональные требования (NFR)
    Задают качественные характеристики системы: производительность, масштабируемость, надёжность, безопасность, удобство использования, совместимость и т.п. Пример: «Система должна поддерживать до 10 000 одновременных пользователей без падения производительности».

  • Переходные требования
    Как и в BABOK, это временные условия, необходимые для миграции, обучения, интеграции или отката. Пример: «Данные из устаревшей CRM-системы должны быть перенесены в новую без потерь».

Для технических специалистов понимание различий между функциональными и нефункциональными требованиями критически важно: первые определяют логику работы, вторые — границы допустимого поведения. Игнорирование NFR часто приводит к тому, что система «работает», но «не масштабируется», «не защищена» или «непригодна в эксплуатации».

Процессы управления требованиями​

Управление требованиями — это не разовое событие, а непрерывный цикл, включающий следующие ключевые этапы:

  1. Планирование управления требованиями
    На этом этапе определяется, как именно будет вестись работа с требованиями: какие методы сбора будут использованы, как будет осуществляться приоритизация, как будут фиксироваться изменения, кто участвует в согласовании и т.д. Результат — План управления требованиями (Requirements Management Plan, RMP).

  2. Разработка требований
    Включает:

    • сбор (elicitation) — извлечение информации от заинтересованных сторон,
    • анализ — синтез, структурирование, выявление противоречий и пробелов.

  3. Проверка (verification)
    Убедиться, что требования корректно сформулированы, полны, непротиворечивы и соответствуют стандартам качества.

  4. Управление изменениями
    Любое изменение требований должно проходить формальный процесс: оценка влияния, согласование, документирование, обновление связанных артефактов.

Эти процессы итеративны и могут повторяться на разных этапах проекта — особенно в гибких методологиях, где требования уточняются по мере развития продукта.

План управления требованиями (RMP)​

План управления требованиями — это документ, регламентирующий подход к работе с требованиями в конкретном проекте. Он не описывает сами требования, а определяет процедуры их обработки. В типичный RMP входят:

  • Подход к определению и документированию требований (форматы, шаблоны, инструменты).
  • Методы сбора и анализа (например, интервью, прототипирование).
  • Критерии качества требований (SMART, INVEST и др.).
  • Процедура приоритизации (MoSCoW, значение/усилия и т.п.).
  • Стратегия отслеживания (traceability matrix).
  • Процесс управления изменениями (change control board, workflow).
  • Роли и ответственности (часто в виде матрицы RACI).

Наличие RMP особенно важно в крупных, сложных или регулируемых проектах (например, в банковской сфере, здравоохранении), где отсутствие контроля над требованиями чревато юридическими и финансовыми рисками.

Матрица RACI в контексте требований​

Матрица RACI — инструмент распределения ролей в процессе работы с требованиями. Для каждого артефакта или действия определяются:

  • R (Responsible) — кто выполняет работу (например, бизнес-аналитик составляет спецификацию),
  • A (Accountable) — кто несёт окончательную ответственность за результат (часто product owner или руководитель проекта),
  • C (Consulted) — кто предоставляет экспертную информацию (разработчик, архитектор, юрист),
  • I (Informed) — кто должен быть проинформирован о результате (тестировщики, поддержка).

Пример для функционального требования:

  • R: бизнес-аналитик,
  • A: product owner,
  • C: архитектор и ведущий разработчик,
  • I: команда QA и технический писатель.

Чёткое распределение ролей снижает риск «серых зон» ответственности и ускоряет согласование.

Жизненный цикл требования​

Требование проходит несколько фаз, образующих его жизненный цикл:

  1. Выявление потребностей — понимание проблемы или возможности.
  2. Формулирование — перевод потребности в текст требования.
  3. Анализ и приоритизация — оценка реализуемости, стоимости, влияния.
  4. Согласование и утверждение — валидация с заинтересованными сторонами.
  5. Реализация — разработка и тестирование по требованию.
  6. Верификация и валидация — проверка соответствия.
  7. Поддержка и изменение — обновление при изменении контекста.
  8. Архивирование или утилизация — когда требование устаревает.

Каждый этап сопровождается метаданными: дата создания, автор, статус, версия, связи с другими требованиями и задачами.

Сбор требований — это процесс, когда аналитик вытаскивает на свет то, что заказчик хочет, нуждается и ожидает — даже если сам этого до конца не осознаёт. Обычно сбор требований возлагается именно на бизнес-аналитика, однако системному аналитику тоже придётся с этим работать. Это совокупность методов и техник, направленных на выявление, документирование, анализ и согласование потребностей и ожиданий заинтересованных сторон относительно будущей системы, продукта или процесса.

Требования нужно собирать, чтобы не делать лишнего (тратить время и деньги), чтобы не упустить важное (и не переделывать потом), чтобы все говорили на одном языке (бизнес, IT, QA, маркетинг и другие), и конечно чтобы потом измерить успех, сравнив результат с требованиями.

Имеется множество подходов к сбору требований, и выбор зависит от ситуации, проекта, команды, бюджета, сроков и зрелости бизнеса.

  1. Интервью (Interviews) - это беседа аналитика с заинтересованными лицами (заказчиками, пользователями, экспертами) с целью выявления потребностей, проблем и ожиданий. Его нужно использовать на старте проекта, когда нужно глубоко погрузиться в предметную область, или когда участники не могут сформулировать требования сами. К примеру, аналитик встречается с менеджером по продажам и спрашивает «Как вы сейчас обрабатываете заказы? Что вызывает сложности? Что бы вы хотели автоматизировать?», но это в самом начале. Если же проект уже работает, и задача более узкая, могут быть более простые или наоборот, сложные интервью.
  2. Анкетирование / Опросы (Questionnaires & Surveys) - это сбор информации от большой группы людей с помощью структурированных вопросов (онлайн или на бумаге). Использовать, когда нужно собрать мнения от многих пользователей или получить статистику, приоритеты, наболевшее. К примеру, опрос клиентов о том, какой функцией в личном кабинете пользуются, какую хотели бы видеть.
  3. Мозговой штурм (Brainstorming) - групповая сессия, где участники генерируют идеи без критики, чтобы найти нестандартные решения или выявить скрытые потребности. Использовать для поиска инноваций, когда нужно «взболтать» мышление команды, или на этапе генерации идей для нового продукта. К примеру, можно всей командой из 10 человек собраться и за 45 минут сгенерировать 50 идей, как улучшить текущую ситуацию.
  4. Наблюдение (Observation / Job Shadowing) - аналитик наблюдает, как пользователи выполняют задачи в реальной обстановке, чтобы выявить неочевидные проблемы и реальные процессы (а не те, что «на бумаге»). Используется, когда пользователи не могут точно описать свою работу, или когда есть подозрение, что процессы «в теории» и «на практике» отличаются. Пример - аналитик целый день сидит рядом с оператором колл-центра и видит, что тот 10 раз копирует данные из одного окна в другое, а это можно автоматизировать, к примеру, автозаполнением.
  5. Анализ документов (Document Analysis) - изучение существующих документов — регламентов, инструкций, отчётов, спецификаций, писем, чатов — для выявления скрытых требований и правил. На самом деле, это крупнейший вариант. Используется, когда есть наследие в виде старых систем или процессов, или для понимания юридических, финансовых, нормативных требований. Аналитик может читать договора, законы, копаться в архивах или запрашивать что-то ещё, и находить нужное для работы.
  6. Ролевые игры / Сценарии использования (Use Cases / User Stories / Role Playing) - это моделирование ситуаций взаимодействия пользователя с системой для выявления шагов, условий, исключений и ожидаемых результатов. Используется для описания функциональных требований, в Agile Scrum проектах (через User Story) и чтобы «прожить» сценарий, найти в нём дыры и уязвимости.
  7. Прототипирование (Prototyping) - создание упрощённой модели интерфейса или процесса (бумажной, цифровой, интерактивной), чтобы визуализировать требования и получить обратную связь ДО разработки. Использовать в тех случаях, когда сложно описать словами, для согласования с пользователями, и чтобы избежать дорогостоящих переделок. Самый простой пример - кликабельный макет формы заказа.
  8. Фокус-группы (Focus Groups) - групповое обсуждение с целевой аудиторией под руководством модератора для сбора мнений, реакций, идей. Используется для оценки восприятия нового продукта или функции, для сбора эмоциональной обратной связи. Результаты могут сказать о многом.
  9. Семинары требований (Requirements Workshops) - организованная сессия с участием всех ключевых стейкхолдеров для совместного определения, приоритизации и согласования требований. Использовать, когда нужно быстро согласовать много сторон, для сложных или конфликтных проектов.

Формулирование требований​

Формулирование — это процесс перевода выявленных потребностей в точные, однозначные и проверяемые утверждения. На этом этапе аналитик превращает неформальные высказывания заинтересованных сторон в технически корректные артефакты.

Качественное требование должно обладать следующими свойствами (часто обобщаемыми под акронимом SMART или CARS):

  • Понятность (Clarity) — отсутствие двусмысленностей, жаргона без пояснений, расплывчатых формулировок вроде «интуитивный интерфейс».
  • Полнота (Completeness) — все необходимые условия и контексты явно указаны.
  • Непротиворечивость (Consistency) — требование не вступает в конфликт с другими.
  • Проверяемость (Testability) — по требованию можно составить тест-кейс или сценарий верификации.
  • Реализуемость (Feasibility) — требование технически достижимо в рамках заданных ограничений.
  • Проследимость (Traceability) — возможность связать требование с бизнес-целью и с итоговой реализацией.

Пример неудачной формулировки:

«Система должна быть быстрой».

Пример корректной:

«При 95-м процентиле нагрузки (до 5000 одновременных сессий) время ответа на запрос авторизации не должно превышать 300 мс».

Формулирование требует не только технической грамотности, но и умения задавать уточняющие вопросы, выявлять скрытые допущения и «невысказанные» ожидания.

Декомпозиция задач: вертикальная и горизонтальная​

Декомпозиция — это разбиение сложного требования или функциональности на более мелкие, управляемые компоненты. Это необходимо для планирования, оценки и распределения работ.

Существует два основных подхода:

  1. Вертикальная декомпозиция
    Разбивает функциональность по уровням абстракции: от высокоуровневого пользовательского сценария к детальным шагам реализации. Например:

    • Уровень 1: «Пользователь может оформить заказ».
    • Уровень 2: «Выбор товара → добавление в корзину → ввод данных доставки → оплата».
    • Уровень 3: «Валидация email-адреса при вводе контактных данных».

    Такой подход обеспечивает сквозную реализацию ценности: даже небольшая часть функционала приносит ощутимый результат (MVP-логика).

  2. Горизонтальная декомпозиция
    Разделяет задачу по технологическим слоям: UI, бизнес-логика, база данных, интеграции и т.д. Например:

    • UI-часть: форма оформления заказа,
    • Логика: расчёт итоговой суммы,
    • БД: сохранение заказа в таблицу orders,
    • Интеграция: отправка уведомления в CRM.

    Горизонтальное разбиение удобно для распределения между специалистами (фронтенд, бэкенд), но не гарантирует поставку работающего функционала на ранних этапах.

В современной практике предпочтение отдаётся вертикальной декомпозиции, особенно в Agile-средах, поскольку она поддерживает принцип инкрементальной ценности.

Оценка объёма работ​

Оценка — это прогноз ресурсов (время, усилия, стоимость), необходимых для реализации требований. Точность оценки критически влияет на реалистичность графика и бюджета проекта.

Что оценивается?​

  • Трудозатраты (человеко-часы, человеко-дни),
  • Техническая сложность,
  • Риски (неопределённость, зависимости, интеграции),
  • Необходимость дополнительных исследований (spike’и).

Методы оценки​

  1. Аналоговая (по схожим задачам) — используется историческая статистика.
  2. Параметрическая — расчёт по формуле (например, «1 экран = 20 человеко-часов»).
  3. Экспертная — мнение опытных разработчиков.
  4. Planning Poker / Story Points — относительная оценка в безразмерных единицах, часто применяемая в Scrum.
  5. T-shirt sizing (S/M/L/XL) — грубая категоризация по сложности на ранних этапах.

Алгоритм оценки (рекомендуемый):​

  1. Разбить требование на задачи (по вертикали!).
  2. Уточнить неопределённости (провести spike при необходимости).
  3. Выбрать метод оценки, соответствующий стадии проекта.
  4. Включить буфер на риски (10–30 % в зависимости от новизны).
  5. Утвердить оценку с командой (коллективная ответственность повышает точность).
  6. Зафиксировать допущения и ограничения, на которых строилась оценка.

Важно: оценка — это не обязательство, а прогноз. Чем больше неопределённости, тем шире должен быть диапазон (например, 16–24 часа вместо «20 часов»).

Верификация и валидация: два разных процесса​

Часто эти термины путают, но их различие принципиально:

  • Верификация (Verification) — «делаем ли мы продукт правильно?»
    Проверка, что требования и реализация соответствуют внутренним стандартам, спецификациям и техническим критериям.
    Инструменты:

    • Definition of Ready (DoR) — критерии готовности требования к разработке (полное, понятное, оценено, имеет acceptance criteria),
    • Definition of Done (DoD) — критерии завершения задачи (код написан, покрыт тестами, задокументирован, прошёл ревью),
    • Ревью требований — коллегиальный анализ спецификации на полноту и качество.

  • Валидация (Validation) — «делаем ли мы правильный продукт?»
    Подтверждение, что реализованное решение действительно решает проблему заказчика.
    Инструменты:

    • Согласование с заинтересованными сторонами,
    • Три Amigo — совместная сессия аналитика, разработчика и тестировщика для обсуждения acceptance criteria,
    • User Acceptance Testing (UAT) — тестирование конечными пользователями в реальных условиях,
    • Демонстрации функционала — регулярные показы работающего продукта.

Верификация — внутренний контроль качества; валидация — подтверждение соответствия бизнес-нуждам.

Передача требований команде разработки​

Передача — это не просто «бросание спецификации через стену», а налаживание контекста. Эффективная передача включает:

  • Презентацию требования на планировании (grooming/planning session),
  • Обсуждение acceptance criteria с участием всех ролей (Три Amigo),
  • Демонстрацию прототипов или макетов (если есть),
  • Пояснение бизнес-ценности — зачем это нужно заказчику,
  • Фиксацию открытых вопросов и сроков их закрытия.

Аналитик выступает в роли хранителя контекста: он должен быть доступен в ходе реализации для уточнений, разъяснений и оперативного согласования изменений.

Поддержка в ходе разработки​

Реализация редко идёт строго по изначальному описанию. Возникают вопросы:

  • «А что делать, если поле пустое?»
  • «Какой статус считать “завершённым”?»
  • «Как обрабатывать ошибку интеграции?»

Аналитик обязан:

  • оперативно отвечать на запросы,
  • уточнять или корректировать требования при обнаружении противоречий,
  • участвовать в refinement’е (уточнении) бэклога,
  • поддерживать актуальность документации.

Это неотъемлемая часть цикла управления требованиями.

Спецификация требований к программному обеспечению (SRS)​

Software Requirements Specification (SRS) — это формальный документ, описывающий функциональные и нефункциональные требования к системе, её внешнее поведение, ограничения и взаимодействие с окружением. SRS служит основой для проектирования, разработки, тестирования и приёмки продукта.

Хотя в Agile-средах SRS часто заменяется на гибкие артефакты (бэклог, пользовательские истории), в регулируемых отраслях (медицина, авиация, финансы) и при разработке сложных систем SRS остаётся обязательным элементом жизненного цикла.

Стандартная структура SRS (в соответствии с IEEE 830-1998 и адаптированными практиками)​

  1. Введение

    • Цель документа,
    • Область применения,
    • Определения, аббревиатуры, термины,
    • Ссылки на нормативные документы и источники,
    • Обзор структуры документа.

  2. Общее описание

    • Перспектива продукта (как он вписывается в экосистему),
    • Классы пользователей и характеристики,
    • Ограничения (технические, юридические, временные),
    • Предположения и зависимости,
    • Диаграммы контекста (например, диаграмма потоков данных или Use Case overview).

  3. Функциональные требования

    • Организуются по подсистемам, модулям или пользовательским ролям,
    • Каждое требование имеет уникальный идентификатор (например, FR-101),
    • Описывается триггер, входные данные, поведение системы, выходные данные, ошибочные сценарии.

  4. Нефункциональные требования

    • Группируются по категориям: производительность, безопасность, надёжность, удобство использования, совместимость, масштабируемость и т.д.,
    • Формулируются количественно, где возможно (например, «Время восстановления после сбоя — не более 5 минут»).

  5. Внешние интерфейсы

    • Пользовательские интерфейсы (описание или ссылка на макеты),
    • Аппаратные интерфейсы,
    • Программные интерфейсы (API, протоколы, форматы данных),
    • Коммуникационные интерфейсы (сетевые протоколы, порты).

  6. Приложения

    • Глоссарий,
    • Диаграммы,
    • Примеры данных,
    • Матрица прослеживаемости (если включена в SRS).

SRS не должен содержать решений архитектуры, алгоритмов или деталей реализации — только что система должна делать, а не как.

Типичные ошибки при формулировании и управлении требованиями​

  1. Расплывчатость и неоднозначность
    Использование субъективных формулировок: «удобный», «быстрый», «интуитивный». Такие требования невозможно проверить.

  2. Отсутствие измеримости в нефункциональных требованиях
    «Система должна быть надёжной» — бессмысленно без указания метрик: MTBF, допустимое время простоя, RTO/RPO.

  3. Игнорирование контекста использования
    Требование описано без учёта сценариев, ролей пользователей или исключительных ситуаций.

  4. Смешение уровней абстракции
    В одном документе — стратегические цели и детали UI-элементов — это нарушает структуру и усложняет управление.

  5. Отсутствие прослеживаемости
    Невозможно понять, какое требование реализовано в каком коде или покрыто каким тестом — это ведёт к «утерянным» функциям и регрессиям.

  6. Недооценка нефункциональных требований
    Часто рассматриваются как «второстепенные», хотя именно они определяют эксплуатационную пригодность системы.

  7. Отсутствие версионирования и контроля изменений
    Без фиксации изменений невозможно восстановить причинно-следственные связи при сбоях или спорах.

Почему участники проекта не работают с едиными требованиями?​

Несогласованность возникает не из-за «плохой воли», а из-за системных причин:

  1. Фрагментация источников
    Требования хранятся в разных местах: в Confluence, Jira, Excel, устных договорённостях, email’ах. Единого источника истины нет.

  2. Отсутствие единой терминологии
    Один и тот же термин (например, «аккаунт») может означать разное для бизнеса, разработки и поддержки.

  3. Разные представления о приоритетах
    Бизнес ценит скорость вывода на рынок, разработка — техническое качество, тестирование — покрытие. Без согласованного подхода к приоритизации возникает конфликт.

  4. Изменения без контроля
    Заказчик вносит правки напрямую разработчику, минуя аналитика — документация устаревает, команда работает по разным версиям.

  5. Отсутствие вовлечения технических специалистов на ранних этапах
    Архитектор или ведущий разработчик не участвует в анализе — требования оказываются технически неосуществимыми или избыточно сложными.

  6. Культура «догоняющего» документирования
    Требования оформляются постфактум, «чтобы закрыть процесс», а не как инструмент работы. В этом случае документ становится формальностью.

Подходы к документированию требований​

Выбор подхода зависит от методологии, сложности системы, регуляторных требований и зрелости команды.

1. Классический (водопадный) подход​

  • Используется полная, детализированная SRS до начала разработки.
  • Подходит для проектов с фиксированным объёмом, чёткими границами, высокими требованиями к документации (например, госзаказы, embedded-системы).
  • Плюсы: полнота, юридическая защищённость, чёткие границы.
  • Минусы: негибкость, высокая стоимость изменений.

2. Agile-подход (на основе пользовательских историй)​

  • Требования фиксируются как краткие истории: «Как [роль], я хочу [функция], чтобы [цель]».
  • Детализация происходит по мере надобности (just-in-time).
  • Acceptance criteria и примеры (Given/When/Then) заменяют формальную спецификацию.
  • Плюсы: гибкость, фокус на ценности, быстрая обратная связь.
  • Минусы: риск потери контекста, сложность в регулируемых средах.

3. Гибридный подход​

  • Комбинирует SRS для ключевых модулей (например, ядра системы, интеграций) и пользовательские истории для итеративных улучшений.
  • Часто применяется в enterprise-разработке.
  • Используются living documents: спецификации, обновляемые в процессе разработки и синхронизированные с бэклогом.

4. Model-Based Requirements Engineering (MBRE)​

  • Требования выражаются в виде моделей: диаграмм BPMN, UML, SysML.
  • Поддерживает автоматическую генерацию тестов, прослеживаемость и анализ полноты.
  • Требует специализированных инструментов (Enterprise Architect, IBM Rhapsody и др.).

5. Specification by Example (SBE)​

  • Требования формулируются через конкретные примеры поведения.
  • Формат: «Если пользователь вводит email без @, система показывает ошибку: “Некорректный формат email”».
  • Легко трансформируется в автоматизированные acceptance-тесты (например, с помощью Cucumber).